home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 136 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.3 KB  |  91 lines
  1. Newsgroups: comp.std.c++
  2. Path: cs.mu.OZ.AU!bounce-back
  3. From: "Eugene Radchenko" <eugene@qsar.chem.msu.su>
  4. Subject: Re: auto_ptr again
  5. Message-ID: <AB29a1naHH@qsar.chem.msu.su>
  6. Originator: fjh@munta.cs.mu.OZ.AU
  7. Sender: news@cs.mu.OZ.AU (CS-Usenet)
  8. Organization: Lab. of Org.Synth., MSU
  9. References: <4djrn4$js1@engnews1.Eng.Sun.COM>
  10. X-Original-Date: Wed, 24 Jan 1996 17: 29:22 +0300 (MSK)
  11. Date: Thu, 25 Jan 1996 05:31:18 GMT
  12. Approved: fjh@cs.mu.oz.au
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMQcVz+EDnX0m9pzZAQGsrQF/ZFeVRPL+z2fqrNrJPa+UFvAC5Gq9gwxo
  15.     eLUrB82hQS6ik4zZ9NmbQB8sec6d1MHF
  16.     =Xpnk
  17. X-Mailer: dMail [Demos Mail for DOS v1.23]
  18.  
  19. Hello!
  20.  
  21. clamage@Eng.Sun.COM (Steve Clamage) writes
  22. >In article mKQD@qsar.chem.msu.su, "Eugene Radchenko"
  23. ><eugene@qsar.chem.msu.su> writes:
  24. >>Hi!
  25. >>I would like to suggest returning to the definition of auto_ptr. The fact
  26. >>is, in current form it is almost unusable for most things due to its
  27. >>underlining concept of a single strict ownership. Actually, we need
  28. >>multiple-instance auto_ptr. If, as I suspect, its inclusion was prevented
  29. >>by the problem of efficiently allocating the counter in ref.counted
  30. >>pointer, then we could parameterize auto_ptr WRT not only the type, but
  31. >>allocator as well. Also, we could use doubly-linked list instead. And
  32. >>anyway, it is the implementation problem!
  33. >
  34. >That point has been beaten to death in the C++ committee and also in
  35. >this forum. Some people felt an auto_ptr should be able to have multiple
  36. >owners, but people with experience with this kind of design persuaded
  37. >the committee that auto_ptrs are too hard to use unless they can have
  38. >only a single owner. Thus, ownership is transferred upon copying.
  39.  
  40. Could you explain please? I understand that multi_ap may be harder to
  41. implement, but using them are much simpler. Also, why is it called _copy_
  42. constructor - it is in fact the _move_ constructor. (Generally, is it wise
  43. to call X(X&) the copy constructor?)
  44.  
  45. >That is, single ownership is a deliberate design decision based on the
  46. >semantics an auto-ptr should have. It is not an implementation issue.
  47.  
  48. I never said that strict/multiple ownership is an implementation issue. I
  49. was talking about whether to implement multiple-ownership auto_ptrs using
  50. ref.counting, list or something else.
  51.  
  52. >Unless someone can present new evidence that shows the arguments in favor
  53. >of single ownership are wrong, and in addition shows that multiple
  54. >ownership is always better, this subject won't be reopened in the committee.
  55.  
  56. The fact is, multiauto_ptrs can be used in every place where singleauto_ptr
  57. can. The only possible drawback is the overhead in performance (negligible
  58. as compared to memory allocation - especially for list implementation) and
  59. storage (not so terrible as current compilers are not likely to put
  60. single_ap in register anyway). On the other hand, single_ap can't be put in
  61. STL container, can't be returned from the function, etc. Thus, the only its
  62. possible use is ensuring that temporarily allocated object is deleted on
  63. exception throw. (I would appreciate J.Kanze explaining the workarounds he
  64. mentioned in another follow-up).
  65.  
  66. >(Yes, examples are known where multiple ownership does what you want.
  67. >That doesn't mean it is overall the best design. And nothing prevents
  68. >you from writing your own multiple-owner class.)
  69.  
  70. No offense intended, but what kind of argument is that? The entire C/C++
  71. standard library (with the possible exception of the functions that
  72. directly map to operating system calls) can (especially STL) be
  73. reimplemented by each user - but what good will the standard then be?
  74. I know the standards committee is doing a great and difficult job - but to
  75. me such an attitude seems not very productive from the marketing point of
  76. view.
  77.  
  78.               Best regards                    Genie
  79.  
  80. --
  81. --------------------------------------------------------------------
  82. Eugene V. Radchenko           Research associate, Computer Chemistry
  83. E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290 
  84. Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
  85.                       Moscow State University, 119899 Moscow, Russia
  86. *****************  Disappearances are deceptive  *******************
  87. ---
  88. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  89.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  90.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  91.